Internet Protocol (IP) was created in the 1960's by the United States Advanced Research Projects Agency (ARPA). The Agency's mission was to create instruments useful for military purposes, in particular communications and decentralized computer networks. The original idea was to create connections between military bases using a decentralized communications network with a mesh structure that would permit network function despite significant damage to the country's infrastructure sustained in a military attack. In the early years of its development, the Internet was used for data transfers, principally as file transfer protocol (FTP) sessions.
Use of the Internet spread from the military to the scientific and educational communities in the 1970's and 80's. Propagation of the Internet was, however, slow until the Worldwide Web (WWW) was created. The Worldwide Web was first intended to provide a convenient channel for the transfer of scientific information. However, it caught the attention of the commercial world and in the 1990's an explosive growth of the expansion of the Internet ensued. That explosive growth continues today. The current Internet uses an Internet Protocol referred to as IP version 4 (IPv4). IPv4 uses address fields that are 32 bits long. Although the potential number of IP addresses is 232, over 70% of those addresses have already been assigned and, if as expected the explosive growth of the Internet continues at its current pace, total exhaustion of IPv4 addresses will occur by 2006. Consequently, the Internet Engineering Task Force (IETF) has developed a new Internet standard referred to as IPv6 which uses 128-bit addressing. The address space in IPv6 is intended to accommodate connection of substantially any intelligent electronic device to the IP network. This includes mobile devices.
It is well known that IPv4 and IPv6 are not compatible because of the differences in address space. Consequently, IPv4 and IPv6 networks can only be interconnected by gateway nodes provisioned with both IPv4 and IPv6 network stacks. However, because of the current lack of available IPv4 address space, IPv6 networks are being deployed and connected to the IPv4 network. A need has therefore arisen for equipment and methods to permit IPv6 devices to communicate across the IPv4 network in order to enhance IPv6 device interconnectivity. It is also well known that a data encapsulation technique known as tunneling can be used for transferring IPv6 packets across the IPv4 network. When an IPv6-in-IPv4 tunnel is created, IPv6 packets are encapsulated with IPv4 headers that are used to transfer the packets through the IPv4 network to a predetermined IPv4-IPv6 host or gateway. The establishment of IPv6-in-IPv4 tunnels is a complex process. Traditionally, the tunnels have been constructed using a manual process for setting up tunnel endpoints at edges of the IPv4 network. This is a time-consuming task that requires a considerable level of expertise and experience. Consequently, manual establishment of tunnels is unworkable with mobile devices and beyond the expertise of a majority of users.
Many known IPv6 transition techniques use tunneling to overlay an IPv6 network over an IPv4 network. Some of these techniques are manual, some are automated. RFC1933 entitled “Transition Mechanisms for IPv6 Hosts and Routers” (April 1996), describes how to encapsulate IPv6 packets in IPv4 packets. It also describes how to manually configure an IPv6-in-IPv4 tunnel. However, this is a completely manual process and is therefore not scalable.
An automated technique referred to as “6to4”, is described in RFC3056 entitled “Connection of IPv6 Domains via IPv4 Clouds” (February 2001), which specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain native IPv6 connectivity. It incidentally provides an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address, even if combined with an IPv4 Network Address Translator (NAT).
Another automated technique referred to as “6over4” is described in RFC2529, which is entitled “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels” (March 1999). In accordance with this technique, the IPv4 address of the destination endpoint is embedded in the prefix part of the IPv6 destination address. This allows isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 multicast domain as their virtual local link. Thus, at least one IPv6 router using the same method must be connected to the same IPv4 domain if IPv6 routing to other links is required. This is therefore a host-to-network or a network-to-network mechanism.
Internet draft IETF-ngtrans-isatap dated Apr. 18, 2002 and entitled “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)” specifies a protocol that connects IPv6 hosts and routers (nodes) within IPv4 sites. ISATAP is a transition mechanism that enables incremental deployment of IPv6 by treating the site's IPv4 infrastructure as a Non-Broadcast Multiple Access (NBMA) link layer for IPv6. ISATAP mechanisms use an IPv6 interface identifier format that embeds an IPv4 address—this enables automatic IPv6-in-IPv4 tunneling within a site, whether the site uses globally assigned or private IPv4 addresses. The interface identifier format can be used with both local and global unicast IPv6 prefixes—this enables IPv6 routing both locally and globally. ISATAP mechanisms introduce no impact on routing table size and require no special IPv4 services (e.g., IPv4 multicast).
A semi-automatic establishment of IPv6-in-IPv4 tunnels is described in RFC3053 entitled “IPv6 Tunnel Broker” (January 2001). The tunnel broker described in this document is a worldwide web implementation that permits end-users to select a pre-configured IPV6-in-IPv4 tunnel. However, the system does not support any real negotiation between the end-user and the tunnel broker. If end-users use dynamic IPv4 addresses, a manual operation must be done to update the tunnel broker. This limits the scalability of deploying IPv6 networks, and introduces a considerable onus on inexperienced users.
Consequently, there exists a need for a method and apparatus for automating and simplifying the establishment of IPv6-in-IPv4 tunnels to facilitate adoption and use of IPv6, as well as to ameliorate the transition from IPv4 to IPv6.